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L Physical Interface - Pinout and Signal Definition 

The pinout of the Macintosh DB19 connector is defined below. The third column defines the use 
of those pins for this interface. 



Pin # Macintosh name PCD usag e Comment Macintosh connection 



1 


GND 


GND 




Cold ground 


2 


GND 


GND 




Cold ground 


3 


GND 


GND 




Cold ground 


4 


GND 


GND 




Cold ground 


5 


-12v 


N/C 


DCD to be self-powered! 




6 


+5v 


N/C 


DCD to be self-powered! 




7 


+12v 


N/C 


DCD to be self -powered! 




8 


+12v 


N/C 


DCD to be self-powered! 




9 


N/C 


N/C 






10 


PWM 


N/C 






11 


PHO 


PhaseO 


PhaseO-2 used for handshake 


IWM 


12 


PHI 


Phasel 




IWM 


13 


PH2 


Phase2 




IWM 


14 


PH3 


Phase3 


Used to allow multiple DCD's 


IWM 


15 


/WrReq 


N/C 






16 


HDSel 


N/C 




VIA/6522 


17 


/ENBL2 


/Enable 




IWM 


18 


RD 


ReadData 


Also connected to Sense on IWM 


IWM 


19 


WR 


WriteData 




IWM 



Note that all DCD lines are outputs (from the perspective of the Macintosh) except ReadData, which 
is input. 

WriteData (from the point of view of the Macintosh) provides serial data transmission at 489.58K 
bps (2.042 microsecond data cell). This is because the Macintosh clock is 7.8333 instead of a full 
8.0 MHz. The high-order bit of each byte is always l~a net data rate of 428.38K bps. ReadData 
is bi-modal as a function of PhaseO-2 (described below). In read mode ReadData functions in 
symmetric fashion to WriteData. In Sense mode it has a or 1 "constant" value. For further 
information see Dwg. #343-004 1-B. 

As described below, the eighth bit of each data byte is collected into a group (7 bits to a group) and 
then transmitted separately (with the high-order bit set as required by the IWM). 

XL Handshake and Data Transmission 

Data is transmitted on the WriteData and read from the ReadData lines. The most significant bit 
(MSB) of each byte transmitted by the IWM is always set (this is a requirement of the IWM chip). 
For terminology, we will therefore distinguish between "data bytes" and "transmitted bytes"; data 
bytes have a full eight bits of information while transmitted bytes have sevenbits of information 
with the MSB set. In order to send seven data bytes, eight transmitted bytes must be sent. We 
therefore talk about a "group" of seven data bytes (or eight transmitted bytes). 

The least significant bit (LSB) of each data byte in a group is collected into the seven low order bits 
of an eighth byte (which will become the eighth transmitted byte). The seven MSB's of each data 
byte are shifted right one bit. The MSB of aJl of these eight bytes are then set, becoming a "group" 
of eight transmitted bytes. Figure 1 on the next page shows some example data. 
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Transmitted Bvtes 



MSB 



1 



$31 = 


00110001 




001 10010 

\J\J 1 1 \J\J 1 \J 


$33 = 


00110011 


$34 = 


00110100 


$35 = 


00110101- 


$36 = 


00110110 


$37 = 


00110111- 



MSB 



r 



010 



10011000 
10011001 
10011001 
10011010 
10011010 
10011011 
10011011 



LSB' s 



$98 
$99 
$99 
$9A 
$9A 
$9B 
$9B 

:$D5 



Figure 1 . 

Transforming 7 data bytes into 8 transmitted bytes. 

When sending data from the Macintosh to the DCD, the LSB-byte is sent first, followed by the 
other seven transmitted bytes, in order. Using the sample data from figure 1: 

$D5 $98 $99 $99 $9A $9A $9B $9B 

When sending data from the DCD to the Macintosh, the LSB-byte is sent last, following the other 
seven transmitted bytes, in order. Using the sample data from figure 1: 

$98 $99 $99 $9A $9A $9B $9B $D5 

The phase Hnes plus the sense status of ReadData are used during startup to determine the presence 
of a drive and its type. Subsequently they are used to handshake between the Macintosh and the 
DCD to coordinate data transmission. Note that the Macintosh acts as the master. The states are 
shown in the table below. Note that the phase lines can only change one at a time—one can't go 
instantly from state to 3, for example. 



State 






PhaseO 


Interpretation 














HOST asserted; HOFF asserted; ReadData in sense mode for /HSHK 


1 








1 


HOST asserted; ReadData in data mode 


2 





1 





Idle; ReadData in sense mode for /HSHK 


3 





1 


1 


HOST asserted; ReadData in sense mode for /HSHK 


4 


1 








RESET asserted (DCD performs equivalent of power-up reset) 


5 


1 





1 


ReadData in sense mode; DCD must set ReadData to (unused in Sony) 


6 


1 


1 





ReadData in sense mode; DCD must set ReadData to 1 (# sides in Sony) 


7 


1 


1 


1 


ReadData in sense mode; DCD must set ReadData to 1 ("drive connected") 



After startup the Macintosh will transition through states 6, 7, and 5 to determine that a drive is 
connected and that it is a DCD as opposed to a 1- or 2-sided Sony. 

In fact, it is possible to connect more than one DCD to a Macintosh if they have the proper 
"flow-tiirough" circuit (or if a T-connector with such a circuit is employed). As noted in section I, 
the Phases line is reserved for connecting to multiple DCD's with the possibility of an external 
Sony drive at the end of the chain. Figure 2 on the next page shows a possible flow-through circuit 
(courtesy of Gary Marten). 
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Figure 2. 
Flowthrough Schematic 



As is shown in Figure 2, whenever the /ENBL line is raised (i.e., de-asserted) then the flip-flop in 
the flowthrough circuit will clear, thus clearing any flowthrough circuits down the line. When the 
/ENBL line is lowered (asserting it), then the first DCD is enabled. At this time, the Macintosh will 
go through the ID states (6, 7, and 5) to determine if the device selected is a DCD or an external 
Sony drive. If it is a DCD, then the Macintosh may toggle Phase3 to enable the next device in the 
chain (and disable the current DCD). Once again, the Macintosh should check the ID states to see if 
another device exists, and if so, what kind. This can be repeated through all the devices chained 
together. Note: Any DCD connected to the Macintosh must support this flowthrough circuit so 
that the Macintosh does not assume there is an infinite sequence of DCD's connected. If a DCD 
does not support additional chaining, it must support "phantom" states (i.e., returning a 1 for all 
states 5, 6, and 7) after the "next" DCD has been selected. In this way, the Macintosh can know it 
has reached the end of the chain. 



Following the startup handshake, states 0-3 are used to transmit data between the Macintosh and 
DCD. As described in the next section, transmissions are always paired—Macintosh to DCD 
followed by a response from the DCD to Macintosh. Thus it is always clear which is the reader 
and which is the writer. 



Macintosh to DCD Handshake 

A diagram of the Macintosh-to-DCD handshake is shown in figure 3 on the next page. 



When the Macintosh wants to transmit it transitions to state 3 via the pahse lines (asserting that it 
wants to send a command) and polls ReadData (the IWM Sense bit). When it goes low indicating 
that the DCD is ready to receive, the Macintosh transitions to state 1 and sends a sync byte (either 
$AA or $96) followed by transmitted bytes on the WriteData line. Typically this continues to the 
end of the transmission at which point the Macintosh waits for the last transmitted byte to go out, 
and then transitions to state 3 in order to sense the DCD's /HSHK line again. When it goes high, 
the Macintosh transitions to the idle state, state 2. 
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HOST 
/HSHK 



HOFF 
Data 

State 2 



transmitted data 



> 



1,3 



^^^^ 



transmitted data 



> 



Figure 3. 
Macintosh to DCD Handshake. 



If the Macintosh wants to interrupt the transmission (e.g., to service the SCC chip) it sets the phase 
lines to state (HOFF asserted). After completing the transmission of the current group of eight 
transmitted bytes, WriteData becomes invalid. Tlie DCD indicates its acknowledgement of the 
Hold-off by de-asserting ReadData (/HSHK). When the Macintosh is ready to resume 
transmission it cycles briefly through state 1 to state 3, waits for /HSHK, transitions to state 1, 
sends the same sync byte as at the beginning of the transmission, and then restarts transmitting with 
the group that was interrupted. Note: If interrupts are occuring with high frequency, then it is 
possible for the Macintosh to do a hold-off in the middle of the same (restarted) group over and 
over again, potentially forever. 

In order to abort a command, the Macintosh must do a hold-off first (by transitioning to state 0) and 
then de-assert both HOST and HOFF by transitioning straight to state 2. The only place in which a 
command may not be aborted is when the DCD is waiting for a sync byte. 

DCD to Macintosh Handshake 



HOST 
/HSHK 

HOFF 

Data 

State 



- ^sync^ 



transmitted data 



> 



1,3 



" ^sync^ 



transmitted data 



> 



1,2 



Figure 4. 
DCD to Macintosh Handshake. 



When the DCD wants to transmit (a response to a command) it asserts /HSHK. When the 
Macintosh senses this on ReadData (sense mode) it transitions briefly through state 3 to state 1 and 
begins reading data (from ReadData in data mode). Following reception of a sync byte (which is 
always $AA) actual data is received until /HSHK is de-asserted. The Macintosh transitions briefly 
through state 3 back to the idle state 2. 

If the Macintosh must interrupt its reception it transitions to state (HOFF asserted) and can then 
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ignore the rest of the group in progress. The DCD de-asserts /HSHK following its transmission of 
the last byte of the group. When the Macintosh is ready to resume it de-asserts HOFF, 
transitioning briefly through state 1 to state 3. When /HSHK is asserted it transitions to state 1 
where it reads a sync byte ($AA again) and then restarts reading data with the group that was 
interrupted. Note: If interrupts are occuring with high frequency, then it is possible for the 
Macintosh to do a hold-off in the middle of the same (restarted) group over and over again, 
potentially forever. 

XXL. Command. Status and Data Formats 

Provided here are the formats for Status, MultiBlock Read, and MultiBlock Write. The 
synchronizing bytes ("sync-bytes") are shown in bold-face before the data bytes (NOTE: since the 
sync-bytes are sent "raw" over the IWM, they will always have the hi-bit set). 

For the status byte that is returned on some commands, only three bits are defined. The most 
significant bit indicates "operation failed". The Macintosh will only retry or fail when this is set. 

Const 

{status bits} 
statopfailed = $80; 
stat_softerr =$40; 
stat_wam = $20; 

The "softerr" bit indicates some other exceptional condition. This would indicate to a user 
diagnostic that further information should be queried from the drive. Some examples of 
exceptional conditions that are not fatal are 1) a block was spared during the last operation, 2) a 
recoverable seek error occured, or 3) a recoverable ECC error occured. 

The "warn" bit indicates that the condition of the disk currently is in doubt. Currently, the only 
condition that would set this bit is having less than five spare blocks. The operating system can 
take this warning and notify some application (perhaps the Finder) to post a warning to the user. 

MultiBlock Read 



Mac 


AA 


00 


#blks 


block (h,m,l) 


pad 


chk 






















DCD 


AA 


80 


#blks 


Stat 


pad pad 


pad 


data 


chk 




















DCD 


AA 


80 


#-1 


Stat 


pad pad 


pad 


data 


chk 










• 
• 
• 










DCD 


AA 


80 


1 


Stat 


pad pad 


pad 


data 


chk 



or 



If checksum error then NAK 



DCD 



AA 



7F 



pad pad pad pad pad 
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Note that the command includes only one byte for the block count. The (possibly multiple) 
reponses will decrement the sequence #, starting at the number of blocks. For example, if the 
Macintosh requests 10 blocks, the sequence numbers will go from 10 to 1. 

MtfUiPlQcH WrUe/Writg-Ygrify - 
Mac 



96 



01 



#blks 



block (h,m,l) pad 



data 



chk 



Mac 



DCD 



Mac 
DCD 



AA 


81 


#blks 


Stat 


pad 


pad 


pad 


chk 






or 
























96 


41 


#-1 


pad 


pad 


pad 


pad 




data 


chk 
























AA 


81 


#-1 


Stat 


pad 


pad 


pad 


chk 






or 


► 








• 
• 
• 














96 


41 


1 


pad 


pad 


pad 


pad 


data 


chk 
























AA 


81 


1 


Stat 


pad 


pad 


pad 


chk 






or 


^ 



If checksum error then NAK 



DCD 



AA 



7F 



pad pad pad pad pad 



chk 




In this case, when the block count is greater than 1, the sequence numbers start at one less than the 
block count and continue down to one this is because the first block (sequence number "count") is 
included with the command. The first block of data is sent with the command in order to optimize 
one-block writes, of which there seem to be a lot in the Macintosh. 

Note that there are three bytes of padding between the sequence number and the write data when 
sending more than one block. This is so that the data will line up the same during each 
write-transmission, which should make it easier for coding. 



Status 
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AA 



03 



pad pad pad pad pad 



chk 



AA 



83 



pad 



Stat 



pad pad pad identity block 



chk 



or —I 



If cliecksum error then NAK 



AA 


7F pad 


pad 


pad pad 


pad 


chk 




The identity block need be only 288 bytes long, but a total of 532 bytes are still sent. The 
manufacturer may place any other information in the last 244 bytes. Assuming a truly "packed" 
structure, the ID block can be defined as follows: 

CONST 



{ Device Characteristics } 



Mountable 


= $80; Writej)rotected 


= $08; 


Readable 


= $40; Iconlncluded 


= $04; 


Writable 


= $20; Disk In Place 


= $02; 


Ejectable 


= $10; 




TYPE 






byte 


= 0..$FF; 




threebytes 


= 0..$FFFFFF; 




ID Block = packed record 






DeviceType: 


word; 


{ Device type } 


DeviceManuf: 


word; 


{ Device Manufacturer, Apple =1} 


DeviceCharacten 


byte; 


{ Characteristics of device } 


Nuin_Blocks: 


threebytes; 


{ Number of blocks on device } 


Num_Spares: 


word; 


{ Number of spare blocks left } 


Niim_BadBlocks: 


word; 


{ Number of bad blocks currently } 


ManufJReserved: 


packed array [0.51] of byte; 


{ Reserved for manufacturer info} 


"^^''^Icon: 


packed array [0.255] of byte; 


{ Icon + mask for device } 


Filler: 


packed array [0..191] of byte; 


{ Filler bytes to make it 512 bytes } 


end; 
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Data Transmission From Drive to Mac 



Mac 

Holdoff I 

Ren6 | | | 

Data <^y ^ ^ta > <^y ^ 

^ to ^ tl ^ a ^ 6 ^ t4 ^ t5 ^ t6 ^ ^ t7 ^ t8 ^ t9 



tO - Ren6 will wait forever for Mac to respond to handshake, 
tl - Ren6 will send sync within 33us. 

t2 - Mac may assert holdoff anywhere in a group. That group will be ignored and will not be included in the checksunL 

6 - Ren6 will acknowledge the holdoff immediately after the last byte of the group is sent 

t4 - Must be a minimum of lOOus. After that, Ren6 will wait forever for holdoff to de-assert. 

t5 - Ren6 will respond to de-assertion of holdoff within 18us after t4. 

t6 - Transmission starts with group that was interrupted by holdoff within 34us. 

t7 - Data transmission time is dependent on the number of groups sent (8 bytes * byte time * number of groups). 

t8 - Ren6 signals end of transmission within 3us of last byte loaded into IWM. Mac wiQ received it one byte time later. 

t9 - Ren6 will wait forever for Mac to de-assert. 



Data Transmission From Mac to Drive 



Mac 

Holdoff I 

Rene | | | 

Data ^y^^ ^ta > < ^^^ data ^ 

^ to ^ tl ^ a ^ t3 ^ t4 ^ t5 ^ t6 ^ ^ t7 ^ t8 ^ t9 



tO - Ren6 normally responds to Mac in 14us, but may take as long as 2 seconds if doing self test, 
tl - Rene will wait forever for a valid sync byte. 

t2 - Mac may assert holdoff anywhere in a group. That group will be ignored and will not be included in the checksum. 

t3 - Ren6 will acknowledge the holdoff immediately after the last byte of the group is received 

t4 - Must be a minimum of 70us. After that, Ren6 will wait forever for holdoff to de-assert 

t5 - Rene will respond to de-assertion of holdoff within 14us after t4. 

t6 - Same as tl. Transmission starts with group that was interrupted by holdoff. 

tl - Data transmission time is dependent on the number of groups sent (8 bytes * byte time * number of groups). 
t8 - Ren6 acknowledges end of transmission within 3us of last byte received. 
t9 - Rene will wait forever for Mac to de-assert. 



Read Commands haue the format: 

k 7 byUs — 



7*n byt«£ 



IC o —can d PcroMttrs i* Podll 



Chk 



Rspns 


Stall 


Stal2 


Slots 


Stat4 


Pod RMd Buffer 




Chk 



Ulrfte Commands haue the format: 



1* — 


7 byt« 


— ►I^ 7^ byt«s 


^ 




[CoMond PorcMtters I-i- Pod]] 


Urite Buffer 




Chk 



Rspns 



Stall 



Stat2 



Stats 



Stat4 



Chk 



Cwi a uniqut number for Mch rn— fnfl fkvMt con do. 
Pod — 0-6 bytes used to pod o block out to a Multiple of 7 bytes. 
Chk — a checksue on the entire block of data being transferred. 
Rspns — C O— an d response byte"Cedi'$80. 

Statx — standard status bytes relumed by aleost all coMonds. 



System Commands: 

Reod Block 



Mrite Block 



$00 


Cnt 


Block <H,H,L> 


>:^Pad $; 


Chk 




















$0i 


Cnt 


Block <H,M,L> 


f%Pod%^ 


Urite Buffer 


CN^ 



Diagnostic Commands: 

Reod Device ID 



$02 



Chk 



Data Rtcal/ 
Broke Releose 

Set Recovery 
Soft Reset 
Pork 

Diagnostic Read 
Read Heoder 
Diagnostic Unite 
Ruto Offset 
Read Spare Table 
Wr i te Spare Table 
Format Track 
Rbort Status 
Servo Reset 



Control ier Status 


$03 


0-6 


Pad S^^^^gJ:^ 


Chk 






Servo Status 


$04 


0-8 




Chk 






Servo CoMMnd 


$05 


CoMKnd bytes 


:$:Pod^J 


Chk 








$06 


Trock (H,L> Head Sect 


Flags 


Chk 




$0B 


Sect 


Flogs 


i;^^^Pod 


Chk 




$00 


Sect 


Flags 




Chk 



$0D 



Sect 



Urite Buffer 



Chk 



$0E 



Chk 



$0F 



Chk 



$10 


$F0 


$78 


$3C 


$1E 


^^Pad^B^ 

\ \ \ \ V v. V \ V V \ y \ \ \ ^ 


H^ite Buffer 


Chk 




















$11 


$F0 


$78 


$X 


$1E 


$:Pod 


Chk 







$13 



Chk 



$14 



Chk 



Diagnostic Commonds (neui stuff): 



Reod Track 



$15 



Sect 



Flags 



t^;^$^$ Pod ^^^^^^^^^s^^i 



Chk 



tt^ltt Track 



$16 


Stct 


Flogs 




UriU Buffer 


Chk 



